I don't think a general "refresh after command" is a desired function. Depending on the attached device it may also fail (e.g. when updating the internal state in the device takes longer than it takes the binding to issue the state request).

Can you show describe what exactly you are doing? What items are connected to the channel, why are there several items, do you send commands to all items (or only one) and what exactly do you expect to happen? At best, show the thing or at least the channel configuration.

Yes,

I have the following configuration for an LED strip:

Thing UID: http:url:2bcdb351df
Base URL: http://192.168.10.11/
....
Channel UID: http:url:2bcdb351df:led0
State URL Extension: state
Command URL Extension: set?status=%2$s
On Value: 1
Off Value: 0
Increase/Decrease Step 1
Color Mode RGB

And 3 items bound to the channel

• Switch
• Dimmer
• Color

Why do you need three items for that? The Color item accepts all commands that Switch or Dimmer accept.

In the color item I see only three bars for Hue, Saturation, Brightness how can I do the rest?

Which UI?

Am not sure is the default UI !

  - component: oh-toggle-card
    config:
      item: Backlight_LED

 - component: oh-slider-card
    config:
      item: Backlight_LED_Dimmer
      label: true
      scale: true
      scaleSubSteps: 5

  - component: oh-colorpicker-card
    config:
      item: Backlight_LED_Color
      sliderLabel: true

I didn't check, but can't you link Backlight_LED_Color in the oh-toggle-card? That should work. If it is not possible, that's an UI bug.

My friend, I have checked what you have suggested and it works the same.

However when triggering a command the state of the channel is not updated (a refresh command has to be fired)
e.g. from off to on the color and brightness items do not know the exact value since the command triggered is only "turn on" !

Anyway the refresh ability is already implemented what I have suggested is to trigger it quicker than waiting the timeout timer to be passed ! Other protocols like Tuya do the same thing, a feedback from the device is updating the state after a command is fired check my repo: https://github.com/constambeys/openhab-addons-tuya

I still don't understand why this is necessary, but we can add it. However, it should be configurable with a default behavior that is the same as the current one.

@constambeys to get this merged i suggest we make this configurable.
With a simple configuration parameter refreshAfterCommand that defaults to false when set to false, the old behaviour applies. Agree? Let me know if you need any help.

Is it ok ?

Thanks for updating this PR. I think this is ready, just one minor thing is left and that is to add this configuration parameter to the readme.md